[Previous] [Next] [Index]
[Thread]
Re: GSS API (as a DLL)...
>> My plan was to require the client and server be run with SETUID to be able
>> to get at the key database.
This strikes me as an extremely poor idea. Setuid executeables are
asking for trouble. Make sure the server has the right privs to read
the server keys as is, and use something real for the client.
>> Its easier to protect the cluster secret key than piddle round with
>> protection like... The observation is that on any multi-user system
>> there is no way of stopping the sysop from finding out such a key
>> unless it is physically protected (smartcard). Thus instead of
>> piddlin' about giving every user their own key and further piddling to
>> distribute it, best have as few keys to go "walkies".
With Kerberos, the secret is only around as long as you are logged in,
and it expires after 8 hours. This gives each user his own key, and
although the superuser can get limited access, it doesn't do him much
good. IMHO, host-level granularity is useless in most environments.
Also, the model of multi-user machines is becoming less and less
common. Many clients run MacOS, DOS, or Windows, all of which are
inherently single-user. And many unix workstations sit on the desk of
the sole user; no administrator to be worried about here. This is the
model I work from.
Marc
Follow-Ups: